في حين شهد العامين الماضيين عددًا من المقترحات لتوسيعات تقترح تحالفات لبيتكوين، كان هناك دائمًا شك بين الخبراء في أنه يمكن أن تكون التحالفات ممكنة دون أي توسيعات. جاءت الأدلة على ذلك بشكلين: تصاعد تشكيلة من الحسابات غير المعتقدة في السابق في (وتوج بمشروع BitVM لتنفيذ كل ترميز RISC-V) وسلسلة من "الفرص الضائعة" التي وجد بها مطورو بيتكوين طرقًا يكون فيها التحالفات ممكنة، لولا بعض الحقائق الغريبة التاريخية ل .
طور إيثان هيلمان وأفيهو ليفي وفيكتور كوبولوف وأنا نظامًا يثبت أن هذا الشك كان مستندًا جيدًا. نظامنا، كوليدر، يمكن أن يتيح العهود على بيتكوين اليوم، بناءً على افتراضات التشفير المعقولة وبتكلفة محتملة تبلغ حوالي 50 مليون دولار لكل عملية (بالإضافة إلى بعض الأبحاث والتطوير).
على الرغم من التكاليف الخارجة عن المألوف لاستخدام الكوليدر، إلا أن إعداده رخيص للغاية، والقيام بذلك (بجانب آلية الإنفاق العادية، باستخدام تابروت لفصل الاثنين) قد ينقذ عملاتك في حال ظهور كمبيوتر كمياء فجأة ويفجر الـ 01928374656574839201.
لا شك أن العديد من القراء، بعد قراءة هذه الادعاءات، يرفعون حاجب واحد نحو السماء. بحلول الوقت الذي تنتهي من قراءة هذه المقالة، سيكون الحاجب الآخر مرتفعًا بنفس الارتفاع.
العهود
سياق هذا النقاش، بالنسبة لأولئك الذين ليسوا على دراية، هو أن بيتكوين يحتوي على لغة برمجة مدمجة، تسمى بيتكوين، والتي تُستخدم لتفويض إنفاق العملات. في أوائل أيامها، كانت بيتكوين تحتوي على مجموعة غنية من أوامر العمليات الحسابية التي يمكن استخدامها لتنفيذ عمليات حسابية تعسفية. ولكن في صيف عام 2010، قام ساتوشي بتعطيل العديد من هذه الأوامر بطلب لإنهاء سلسلة من الشوائب الخطيرة. (عودة إلى الإصدار الذي كان قبل عام 2010 هو الهدف من مشروع استعادة بيتكوين الكبير؛ OP_CAT هو اقتراح أقل طموحًا في نفس الاتجاه.) فكرة العهود - المعاملات التي تستخدم بيتكوين للتحكم في كمية ووجهة عملاتها - لم تظهر لعدة سنوات أخرى، ولم يأت الإدراك بأن هذه الأوامر كانت كافية لتنفيذ العهود حتى وقت لاحق. في تلك النقطة، كانت المجتمع كبيرة وحذرة للغاية حتى لا يكون ببساطة "إعادة تمكين" الأوامر القديمة بنفس الطريقة التي تم فيها تعطيلها.
العهود هي بناء فرضي يسمح للمستخدمين بالتحكم ليس فقط في الشروط التي يتم بها إنفاق العملات ، ولكن أيضًا في وجهتها. هذا هو الأساس للعديد من البناء المزعوم على بيتكوين ، من الأنفاق والمحافظ المحدودة بالسعر ، إلى آليات سوق الرسوم الجديدة مثل حمامات الدفع ، إلى بناء أقل جذاب مثل التمويل الموزع و MEV. تم إنفاق الملايين من الكلمات في مناقشة مدى الرغبة في العهود وما ستفعله لطبيعة بيتكوين.
في هذه المقالة سأتجنب هذا الجدل، وأُقدم حجة ببساطة بأن العهود ممكنة بالفعل على بيتكوين؛ وأننا في النهاية سنكتشف كيف يمكن أن تتم (دون تكاليف حوسبة كبيرة أو افتراضات تشفيرية مشكوك فيها)؛ وأن جدلنا حول تمديدات جديدة لبيتكوين لا ينبغي أن يُصاغ كما لو أن التغييرات الفردية ستكون الخط الفاصل بين مستقبل خالٍ من العهود أو مستقبل مليء بالعهود لبيتكوين.
التاريخ
على مر السنين، تطوّر تقليد إيجاد طُرُق إبداعية لفعل الأشياء غير التافهة حتى مع وجود موارد محدودة. كانت شبكة البرق أحد الأمثلة على ذلك، فضلاً عن أفكار أقل شهرة مثل المدفوعات الاحتمالية أو مكافآت التصادم لوظائف التجزئة. لاحظت الحالات الحدية المظلمة، مثل علة SIGHASH_SINGLE أو استخدام استرداد المفتاح العام للحصول على "تجزئة معامل" داخل المترجم، وتم استكشافها، ولكن لم يجد أحد طريقة لجعلها مفيدة. وفي الوقت نفسه، تطوّرت بيتكوين نفسها لتكون أكثر تحديدًا، مغلقة العديد من هذه الأبواب. على سبيل المثال، أزال Segwit علة SIGHASH_SINGLE وفصل بيانات البرنامج صراحة عن بيانات الشاهد؛ وتخلص Taproot من استرداد المفتاح العام، الذي كان يوفر المرونة على حساب تقويض الأمان للتواقيع المتكيفة أو التواقيع المتعددة.
على الرغم من هذه التغييرات، استمرت القرصنة، وكذلك الاعتقاد بين الحاصلين على البتكوين بأنه بطريقة ما، يمكن العثور على حالة حافة قد تمكن من تمكين الدعم في بيتكوين. في بداية عقد 2020، حدث تطوران بشكل خاص. الأول كان اكتشافي الخاص أن العهود القائمة على التوقيع لم تمت مع استرداد المفتاح العام، وبأنه بشكل خاص، إذا كان لدينا حتى عملية تعطيل واحدة -- OP_CAT -- فإن هذا سيكون كافيًا لبناء عهد فعال بشكل معقول. الآخر كان BitVM، وهو طريقة جديدة لإجراء عمليات حسابية كبيرة عبر عدة معاملات، مما ألهم كمية هائلة من البحوث في العمليات الحسابية الأساسية داخل المعاملات الفردية.
ألهم هذان التطوران الكثير من النشاط والإثارة حول العهود ، لكنهما بلورا أيضا تفكيرنا حول القيود الأساسية ل . على وجه الخصوص ، بدا الأمر كما لو أن العهود قد تكون مستحيلة بدون أكواد تشغيلية جديدة ، حيث تم إدخال بيانات المعاملات فقط من خلال توقيعات 64 بايت ومفاتيح عامة 32 بايت ، في حين أن رموز التشغيل التي تدعم BitVM يمكن أن تعمل فقط مع كائنات 4 بايت. أطلق على هذا الانقسام اسم "صغير" و "كبير" ، وأصبح العثور على الجسر بين الاثنين مرادفا (في رأيي ، على الأقل) لإيجاد بناء العهد.
التشفير الوظيفي وPIPEs
لوحظ أيضًا أنه باستخدام قليلاً من رياضيات القمر ، قد يكون من الممكن القيام بعهود تمامًا داخل التوقيعات ذاتها، دون مغادرة BigBIT. صاغ جيريمي روبين هذه الفكرة في ورقته FE'd Up Covenants، التي وصفت كيفية تنفيذ العهود باستخدام جسيم تشفير وهمي يُسمى functional التشفير. بعد أشهر، اقترح ميشا كوموروف مخططًا محددًا يُسمى PIPEs والذي يبدو أنه يجعل هذه الفكرة الوهمية حقيقة.
هذا تطور مثير للإعجاب، على الرغم من أنه يعاني من قيود رئيسية: الأولى هي أنه يتضمن إعدادًا موثوقًا به، مما يعني أن الشخص الذي ينشئ العهد قادر على تجاوز قواعد العهد. (هذا أمر جيد لشيء مثل الخزائن، حيث يمكن الوثوق بمالك العملات لعدم تقويض أمانه الخاص؛ ولكنه ليس جيدًا بالنسبة لشيء مثل حمامات الدفع حيث لا تملك العملات في العهد من قبل منشئ العهد.) القيد الآخر هو أنه يتضمن تشفيرًا حديثًا غير واضح الخصائص الأمنية. ستختفي هذه القيود الأخيرة مع المزيد من البحث، ولكن الإعداد الموثوق به يعد جزءًا أساسيًا من النهج الوظيفي-التشفير.
مفاعل الجسيمات
يأتي هذه النظرة العامة لنا إلى الوضع الحالي: نود العثور على طريقة لتنفيذ العهود باستخدام النموذج الحالي لبيتكوين، ونعتقد أن الطريقة لفعل ذلك هي العثور على نوع من الجسر بين "الكبير" لتواقيع المعاملات و"الصغير" للحسابات التعسفية. يبدو أنه لا يمكن لأي أوبكود أن يشكل هذا الجسر مباشرة (انظر الملحق أ في ورقتنا لتصنيف جميع أوبكودات بالنسبة لحجم مدخلاتها ومخرجاتها). الجسر، إذا كان موجودا، سيكون نوعًا من البنية التي تأخذ كائنًا كبيرًا وتظهر أنه مساوٍ تمامًا لاتحاد عدة كائنات صغيرة. يبدو، بناءً على تصنيفنا لأوبكودات، أن هذا أمر مستحيل.
ومع ذلك، في علم التشفير غالبًا ما نضعف مفاهيم مثل "مطابقة تامة"، بدلاً من ذلك نستخدم مفاهيم مثل "غير قابل للتمييز عن طريق الحساب" أو "غير قابل للتمييز إحصائيًا"، وبالتالي نتهرب من نتائج الاستحالة. ربما، من خلال استخدام هياكل التشفير المدمجة لـ Big - القيم المتجهية والتواقيع البيضاوية - ومن خلال تعكسها باستخدام بناء BitVM في Small، يمكننا أن نجد طريقة ليظهر أن كائنًا كبيرًا كان "غير قابل للتمييز عن طريق الحساب" عن سلسلة من الأشياء الصغيرة؟ مع Collider، هذا بالضبط ما فعلناه.
ماذا يعني هذا؟ حسنًا، تذكر وظيفة الالتجزئة اصطدام المكافأة التي ذكرناها سابقًا. فرضية هذه المكافأة هي أن أي شخص يمكنه "تصادم" وظيفة الالتجزئة، من خلال تقديم اثنين من المدخلات التي تعطي نفس الإخراج الخاص بالالتجزئة، يمكنه أن يثبت في Big أنه فعل ذلك، وبالتالي يمكنه المطالبة بالمكافأة. نظرًا لأن مساحة المدخلات لوظيفة الالتجزئة أكبر بكثير (جميع سلاسل البايتات بحجم يصل إلى 520 بايتًا) من مساحة الإخراج (سلاسل البايتات بحجم 32 بايتًا تمامًا)، رياضيًا يجب أن تكون هناك الكثير من مثل هذه التصادمات. ومع ذلك، باستثناء SHA1، لم يجد أحد طريقة أسرع لـ العثور على هذه التصادمات سوى بمجرد استدعاء وظيفة الالتجزئة مرارًا وتكرارًا ورؤية ما إذا كانت النتيجة تتطابق مع محاولة سابقة.
ويعني هذا في المتوسط أن المستخدم سيحتاج إلى قيام على الأقل بـ 2^80 عمل، أو مليون مليون مليون مليون تكرار، للعثور على تصادم لوظيفة 160 بت التجزئة مثل SHA1 أو RIPEMD160. (في حالة SHA1، هناك اختصار إذا كان المستخدم قادرًا على استخدام مدخلات بتنسيق معين؛ ولكن بناءنا يحظر هذه، لذلك يمكننا تجاهل هذا الهجوم لأغراضنا.) وهذا يفترض أن المستخدم لديه كمية غير محدودة من الذاكرة للعمل معها؛ مع افتراضات أكثر واقعية، نحتاج إلى إضافة عامل آخر من حوالي مائة أو نحو ذلك.
إذا قمنا بتخيل أنه يمكن حساب SHA1 و RIPEMD160 بكفاءة مثلما تقوم ASICs بحساب SHA256 في بيتكوين ، فإن تكلفة مثل هذا الحساب ستكون تقريباً نفس تكلفة 200 كتلة ، أو حوالي 625 BTC (46 مليون دولار). هذا مبلغ كبير ، ولكن العديد من الأشخاص لديهم وصول إلى مثل هذا المبلغ ، لذلك هذا ممكن.
للعثور على اصطدام ثلاثي، أو ثلاث إدخالات تتطابق في الناتج نفسه، سيستغرق حوالي 2^110 عمل، حتى مع افتراضات سخية جدًا حول الوصول إلى الذاكرة. للحصول على هذا الرقم، نحتاج إلى إضافة عامل آخر قدره 16 مليون إلى تكلفتنا - مما يجلب إجمالينا إلى أكثر من 700 تريليون دولار. هذا أيضًا الكثير من المال، وهو مبلغ لا أحد لديه الوصول إليه اليوم.
جوهر بناءنا هو كما يلي: لإثبات أن سلسلة من الكائنات الصغيرة مكافئة لكائن كبير واحد، نجد أولا تجزئة تصادم بين كائن الهدف الخاص بنا (الذي نفترض أن يمكن إعادة عشوائية بطريقة ما، وإلا كنا سنقوم بالبحث عن "ثاني الصورة") وكائن "اختبار المكافئة ". يتم بناء هذه الكائنات اختبار المكافئة بطريقة يمكن تلاعبها بسهولة في Big و Small.
بعد ذلك ، يقوم برنامج البناء لدينا بالتحقق ، في بيتكوين ، من أن كائننا الكبير يتصادم مع مقياس التكافؤ الخاص بنا (باستخدام نفس الأساليب تمامًا كما في التجزئة-مكافأة الاصطدام) وأن سلسلة كائناتنا الصغيرة تتصادم مع مقياس التكافؤ (باستخدام بناء معقد مستوحى جزئيًا من مشروع BitVM ، والموضح بالتفصيل في الورقة). إذا تم اجتياز هذه الفحوصات ، فإما أن كائناتنا الصغيرة والكبيرة هي نفسها ، أو أن المستخدم وجد تصادمًا ثلاثيًا: كائنان مختلفان يتصادمان مع المقياس. ووفقًا لحجةنا أعلاه ، هذا أمر مستحيل.
الاستنتاج
إن الربط بين الصغير والكبير هو أصعب جزء في بناء عهدنا. للانتقال من هذا الجسر إلى العهد الفعلي ، هناك بضع خطوات أخرى ، وهي سهلة نسبيا. على وجه الخصوص ، يطلب العهد أولا من المستخدم التوقيع على المعاملة باستخدام "مفتاح المولد" الخاص ، والذي يمكننا التحقق منه باستخدام رمز التشغيل OP \ _CHECKSIG. باستخدام الجالسر ، نقوم بتقسيم هذا التوقيع إلى أجزاء 4 بايت. ثم نتحقق من أن nonce كان مساويا أيضا لمفتاح المولد ، وهو أمر يسهل القيام به بمجرد تفكيك التوقيع. أخيرا ، نستخدم تقنيات من خدعة Schnorr لاستخراج بيانات المعاملة من التوقيع ، والتي يمكن بعد ذلك تقييدها بأي طريقة يريدها العهد.
هناك بعض الأشياء الأخرى التي يمكننا القيام بها: يصف الملحق C بناء توقيع الخاتم الذي يسمح بتوقيع العملات المعدنية بواسطة أحد مجموعة المفاتيح العامة ، دون الكشف عن أي منها تم استخدامه. في هذه الحالة ، نستخدم الجسر لتفكيك المفتاح العام ، بدلا من التوقيع. يمنحنا القيام بذلك تحسنا كبيرا في الكفاءة مقارنة ببناء العهد ، لأسباب فنية تتعلق ب Taproot ومفصلة في الورقة.
تطبيق نهائي أرغب في جذب الاهتمام إليه، والذي تم مناقشته بإيجاز في القسم 7.2 من الورقة، هو أننا يمكننا استخدام بناء العهد الخاص بنا لاستخراج التجزئة من توقيع Schnorr، ثم إعادة توقيع التجزئة باستخدام توقيع Lamport ببساطة.
لماذا يجب أن نفعل ذلك؟ كما جرى الجدل في الرابط أعلاه، يجعل توقيع لامبورت التوقيع بهذه الطريقة توقيعًا آمنًا ضد الكم على بيانات المعاملة؛ إذا كانت هذه البنية الوحيدة لتوقيع بعض العملات، فإنها ستكون محصنة ضد السرقة بواسطة كمبيوتر كمي.
بالطبع، نظرًا لأن بناءنا يتطلب عشرات الملايين من الدولارات للاستخدام، فلن يقوم أحد بجعل هذا البناء الطريقة الوحيدة لتوقيع عملاتهم. ولكن لا يوجد شيء يمنع شخصًا ما من إضافة هذا البناء إلى عملاتهم، بالإضافة إلى طرقهم الحالية غير الآمنة كما ذكرنا.
ثم، إذا استيقظنا غداً ووجدنا أن أجهزة الكم الرخيصة موجودة والتي تستطيع كسر توقيعات بيتكوين، قد نقترح soft-fork طارئ الذي يعطل جميع توقيعات المنحنى البيضاوي، بما في ذلك إنفاقات Taproot key وكود OP_CHECKSIG. سيجمد هذا عملياً عملات الجميع؛ ولكن إذا كان البديل هو أن تكون عملات الجميع قابلة للسرقة بحرية، ربما لن يكون هناك أي فرق. إذا سمح هذا الsoft-fork الذي يعطل التوقيع بكود OP_CHECKSIG عند استدعاء مع مفتاح المولد (مثل هذه التوقيعات لا توفر أي أمان على الإطلاق، ولا تكون مفيدة سوى كوحدة بناء لتكوينات معقدة مثل تلك لدينا)، فإن مستخدمي بنية توقيعنا Lamport يمكنهم الاستمرار في إنفاق عملاتهم بحرية، دون خوف من الاستيلاء أو السرقة.
بالطبع، سيحتاجون إلى إنفاق عشرات الملايين من الدولارات للقيام بذلك، ولكن هذا أفضل بكثير من 'المستحيل'! ونتوقع ونأمل أن نرى تكلفة هذا اسقاط بشكل كبير، حيث يعتمد الناس على بحوثنا.
هذه مشاركة ضيف من أندرو بويلسترا. الآراء المعبر عنها هي بالكامل ملك له ولا تعكس بالضرورة آراء BTC Inc أو مجلة بيتكوين.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
Collider_: عهد بيتكوين بقيمة 50 مليون دولار بدون أكواد جديدة
في حين شهد العامين الماضيين عددًا من المقترحات لتوسيعات تقترح تحالفات لبيتكوين، كان هناك دائمًا شك بين الخبراء في أنه يمكن أن تكون التحالفات ممكنة دون أي توسيعات. جاءت الأدلة على ذلك بشكلين: تصاعد تشكيلة من الحسابات غير المعتقدة في السابق في (وتوج بمشروع BitVM لتنفيذ كل ترميز RISC-V) وسلسلة من "الفرص الضائعة" التي وجد بها مطورو بيتكوين طرقًا يكون فيها التحالفات ممكنة، لولا بعض الحقائق الغريبة التاريخية ل .
طور إيثان هيلمان وأفيهو ليفي وفيكتور كوبولوف وأنا نظامًا يثبت أن هذا الشك كان مستندًا جيدًا. نظامنا، كوليدر، يمكن أن يتيح العهود على بيتكوين اليوم، بناءً على افتراضات التشفير المعقولة وبتكلفة محتملة تبلغ حوالي 50 مليون دولار لكل عملية (بالإضافة إلى بعض الأبحاث والتطوير).
على الرغم من التكاليف الخارجة عن المألوف لاستخدام الكوليدر، إلا أن إعداده رخيص للغاية، والقيام بذلك (بجانب آلية الإنفاق العادية، باستخدام تابروت لفصل الاثنين) قد ينقذ عملاتك في حال ظهور كمبيوتر كمياء فجأة ويفجر الـ 01928374656574839201.
لا شك أن العديد من القراء، بعد قراءة هذه الادعاءات، يرفعون حاجب واحد نحو السماء. بحلول الوقت الذي تنتهي من قراءة هذه المقالة، سيكون الحاجب الآخر مرتفعًا بنفس الارتفاع.
العهود
سياق هذا النقاش، بالنسبة لأولئك الذين ليسوا على دراية، هو أن بيتكوين يحتوي على لغة برمجة مدمجة، تسمى بيتكوين، والتي تُستخدم لتفويض إنفاق العملات. في أوائل أيامها، كانت بيتكوين تحتوي على مجموعة غنية من أوامر العمليات الحسابية التي يمكن استخدامها لتنفيذ عمليات حسابية تعسفية. ولكن في صيف عام 2010، قام ساتوشي بتعطيل العديد من هذه الأوامر بطلب لإنهاء سلسلة من الشوائب الخطيرة. (عودة إلى الإصدار الذي كان قبل عام 2010 هو الهدف من مشروع استعادة بيتكوين الكبير؛ OP_CAT هو اقتراح أقل طموحًا في نفس الاتجاه.) فكرة العهود - المعاملات التي تستخدم بيتكوين للتحكم في كمية ووجهة عملاتها - لم تظهر لعدة سنوات أخرى، ولم يأت الإدراك بأن هذه الأوامر كانت كافية لتنفيذ العهود حتى وقت لاحق. في تلك النقطة، كانت المجتمع كبيرة وحذرة للغاية حتى لا يكون ببساطة "إعادة تمكين" الأوامر القديمة بنفس الطريقة التي تم فيها تعطيلها.
العهود هي بناء فرضي يسمح للمستخدمين بالتحكم ليس فقط في الشروط التي يتم بها إنفاق العملات ، ولكن أيضًا في وجهتها. هذا هو الأساس للعديد من البناء المزعوم على بيتكوين ، من الأنفاق والمحافظ المحدودة بالسعر ، إلى آليات سوق الرسوم الجديدة مثل حمامات الدفع ، إلى بناء أقل جذاب مثل التمويل الموزع و MEV. تم إنفاق الملايين من الكلمات في مناقشة مدى الرغبة في العهود وما ستفعله لطبيعة بيتكوين.
في هذه المقالة سأتجنب هذا الجدل، وأُقدم حجة ببساطة بأن العهود ممكنة بالفعل على بيتكوين؛ وأننا في النهاية سنكتشف كيف يمكن أن تتم (دون تكاليف حوسبة كبيرة أو افتراضات تشفيرية مشكوك فيها)؛ وأن جدلنا حول تمديدات جديدة لبيتكوين لا ينبغي أن يُصاغ كما لو أن التغييرات الفردية ستكون الخط الفاصل بين مستقبل خالٍ من العهود أو مستقبل مليء بالعهود لبيتكوين.
التاريخ
على مر السنين، تطوّر تقليد إيجاد طُرُق إبداعية لفعل الأشياء غير التافهة حتى مع وجود موارد محدودة. كانت شبكة البرق أحد الأمثلة على ذلك، فضلاً عن أفكار أقل شهرة مثل المدفوعات الاحتمالية أو مكافآت التصادم لوظائف التجزئة. لاحظت الحالات الحدية المظلمة، مثل علة SIGHASH_SINGLE أو استخدام استرداد المفتاح العام للحصول على "تجزئة معامل" داخل المترجم، وتم استكشافها، ولكن لم يجد أحد طريقة لجعلها مفيدة. وفي الوقت نفسه، تطوّرت بيتكوين نفسها لتكون أكثر تحديدًا، مغلقة العديد من هذه الأبواب. على سبيل المثال، أزال Segwit علة SIGHASH_SINGLE وفصل بيانات البرنامج صراحة عن بيانات الشاهد؛ وتخلص Taproot من استرداد المفتاح العام، الذي كان يوفر المرونة على حساب تقويض الأمان للتواقيع المتكيفة أو التواقيع المتعددة.
على الرغم من هذه التغييرات، استمرت القرصنة، وكذلك الاعتقاد بين الحاصلين على البتكوين بأنه بطريقة ما، يمكن العثور على حالة حافة قد تمكن من تمكين الدعم في بيتكوين. في بداية عقد 2020، حدث تطوران بشكل خاص. الأول كان اكتشافي الخاص أن العهود القائمة على التوقيع لم تمت مع استرداد المفتاح العام، وبأنه بشكل خاص، إذا كان لدينا حتى عملية تعطيل واحدة -- OP_CAT -- فإن هذا سيكون كافيًا لبناء عهد فعال بشكل معقول. الآخر كان BitVM، وهو طريقة جديدة لإجراء عمليات حسابية كبيرة عبر عدة معاملات، مما ألهم كمية هائلة من البحوث في العمليات الحسابية الأساسية داخل المعاملات الفردية.
ألهم هذان التطوران الكثير من النشاط والإثارة حول العهود ، لكنهما بلورا أيضا تفكيرنا حول القيود الأساسية ل . على وجه الخصوص ، بدا الأمر كما لو أن العهود قد تكون مستحيلة بدون أكواد تشغيلية جديدة ، حيث تم إدخال بيانات المعاملات فقط من خلال توقيعات 64 بايت ومفاتيح عامة 32 بايت ، في حين أن رموز التشغيل التي تدعم BitVM يمكن أن تعمل فقط مع كائنات 4 بايت. أطلق على هذا الانقسام اسم "صغير" و "كبير" ، وأصبح العثور على الجسر بين الاثنين مرادفا (في رأيي ، على الأقل) لإيجاد بناء العهد.
التشفير الوظيفي وPIPEs
لوحظ أيضًا أنه باستخدام قليلاً من رياضيات القمر ، قد يكون من الممكن القيام بعهود تمامًا داخل التوقيعات ذاتها، دون مغادرة BigBIT. صاغ جيريمي روبين هذه الفكرة في ورقته FE'd Up Covenants، التي وصفت كيفية تنفيذ العهود باستخدام جسيم تشفير وهمي يُسمى functional التشفير. بعد أشهر، اقترح ميشا كوموروف مخططًا محددًا يُسمى PIPEs والذي يبدو أنه يجعل هذه الفكرة الوهمية حقيقة.
هذا تطور مثير للإعجاب، على الرغم من أنه يعاني من قيود رئيسية: الأولى هي أنه يتضمن إعدادًا موثوقًا به، مما يعني أن الشخص الذي ينشئ العهد قادر على تجاوز قواعد العهد. (هذا أمر جيد لشيء مثل الخزائن، حيث يمكن الوثوق بمالك العملات لعدم تقويض أمانه الخاص؛ ولكنه ليس جيدًا بالنسبة لشيء مثل حمامات الدفع حيث لا تملك العملات في العهد من قبل منشئ العهد.) القيد الآخر هو أنه يتضمن تشفيرًا حديثًا غير واضح الخصائص الأمنية. ستختفي هذه القيود الأخيرة مع المزيد من البحث، ولكن الإعداد الموثوق به يعد جزءًا أساسيًا من النهج الوظيفي-التشفير.
مفاعل الجسيمات
يأتي هذه النظرة العامة لنا إلى الوضع الحالي: نود العثور على طريقة لتنفيذ العهود باستخدام النموذج الحالي لبيتكوين، ونعتقد أن الطريقة لفعل ذلك هي العثور على نوع من الجسر بين "الكبير" لتواقيع المعاملات و"الصغير" للحسابات التعسفية. يبدو أنه لا يمكن لأي أوبكود أن يشكل هذا الجسر مباشرة (انظر الملحق أ في ورقتنا لتصنيف جميع أوبكودات بالنسبة لحجم مدخلاتها ومخرجاتها). الجسر، إذا كان موجودا، سيكون نوعًا من البنية التي تأخذ كائنًا كبيرًا وتظهر أنه مساوٍ تمامًا لاتحاد عدة كائنات صغيرة. يبدو، بناءً على تصنيفنا لأوبكودات، أن هذا أمر مستحيل.
ومع ذلك، في علم التشفير غالبًا ما نضعف مفاهيم مثل "مطابقة تامة"، بدلاً من ذلك نستخدم مفاهيم مثل "غير قابل للتمييز عن طريق الحساب" أو "غير قابل للتمييز إحصائيًا"، وبالتالي نتهرب من نتائج الاستحالة. ربما، من خلال استخدام هياكل التشفير المدمجة لـ Big - القيم المتجهية والتواقيع البيضاوية - ومن خلال تعكسها باستخدام بناء BitVM في Small، يمكننا أن نجد طريقة ليظهر أن كائنًا كبيرًا كان "غير قابل للتمييز عن طريق الحساب" عن سلسلة من الأشياء الصغيرة؟ مع Collider، هذا بالضبط ما فعلناه.
ماذا يعني هذا؟ حسنًا، تذكر وظيفة الالتجزئة اصطدام المكافأة التي ذكرناها سابقًا. فرضية هذه المكافأة هي أن أي شخص يمكنه "تصادم" وظيفة الالتجزئة، من خلال تقديم اثنين من المدخلات التي تعطي نفس الإخراج الخاص بالالتجزئة، يمكنه أن يثبت في Big أنه فعل ذلك، وبالتالي يمكنه المطالبة بالمكافأة. نظرًا لأن مساحة المدخلات لوظيفة الالتجزئة أكبر بكثير (جميع سلاسل البايتات بحجم يصل إلى 520 بايتًا) من مساحة الإخراج (سلاسل البايتات بحجم 32 بايتًا تمامًا)، رياضيًا يجب أن تكون هناك الكثير من مثل هذه التصادمات. ومع ذلك، باستثناء SHA1، لم يجد أحد طريقة أسرع لـ العثور على هذه التصادمات سوى بمجرد استدعاء وظيفة الالتجزئة مرارًا وتكرارًا ورؤية ما إذا كانت النتيجة تتطابق مع محاولة سابقة.
ويعني هذا في المتوسط أن المستخدم سيحتاج إلى قيام على الأقل بـ 2^80 عمل، أو مليون مليون مليون مليون تكرار، للعثور على تصادم لوظيفة 160 بت التجزئة مثل SHA1 أو RIPEMD160. (في حالة SHA1، هناك اختصار إذا كان المستخدم قادرًا على استخدام مدخلات بتنسيق معين؛ ولكن بناءنا يحظر هذه، لذلك يمكننا تجاهل هذا الهجوم لأغراضنا.) وهذا يفترض أن المستخدم لديه كمية غير محدودة من الذاكرة للعمل معها؛ مع افتراضات أكثر واقعية، نحتاج إلى إضافة عامل آخر من حوالي مائة أو نحو ذلك.
إذا قمنا بتخيل أنه يمكن حساب SHA1 و RIPEMD160 بكفاءة مثلما تقوم ASICs بحساب SHA256 في بيتكوين ، فإن تكلفة مثل هذا الحساب ستكون تقريباً نفس تكلفة 200 كتلة ، أو حوالي 625 BTC (46 مليون دولار). هذا مبلغ كبير ، ولكن العديد من الأشخاص لديهم وصول إلى مثل هذا المبلغ ، لذلك هذا ممكن.
للعثور على اصطدام ثلاثي، أو ثلاث إدخالات تتطابق في الناتج نفسه، سيستغرق حوالي 2^110 عمل، حتى مع افتراضات سخية جدًا حول الوصول إلى الذاكرة. للحصول على هذا الرقم، نحتاج إلى إضافة عامل آخر قدره 16 مليون إلى تكلفتنا - مما يجلب إجمالينا إلى أكثر من 700 تريليون دولار. هذا أيضًا الكثير من المال، وهو مبلغ لا أحد لديه الوصول إليه اليوم.
جوهر بناءنا هو كما يلي: لإثبات أن سلسلة من الكائنات الصغيرة مكافئة لكائن كبير واحد، نجد أولا تجزئة تصادم بين كائن الهدف الخاص بنا (الذي نفترض أن يمكن إعادة عشوائية بطريقة ما، وإلا كنا سنقوم بالبحث عن "ثاني الصورة") وكائن "اختبار المكافئة ". يتم بناء هذه الكائنات اختبار المكافئة بطريقة يمكن تلاعبها بسهولة في Big و Small.
بعد ذلك ، يقوم برنامج البناء لدينا بالتحقق ، في بيتكوين ، من أن كائننا الكبير يتصادم مع مقياس التكافؤ الخاص بنا (باستخدام نفس الأساليب تمامًا كما في التجزئة-مكافأة الاصطدام) وأن سلسلة كائناتنا الصغيرة تتصادم مع مقياس التكافؤ (باستخدام بناء معقد مستوحى جزئيًا من مشروع BitVM ، والموضح بالتفصيل في الورقة). إذا تم اجتياز هذه الفحوصات ، فإما أن كائناتنا الصغيرة والكبيرة هي نفسها ، أو أن المستخدم وجد تصادمًا ثلاثيًا: كائنان مختلفان يتصادمان مع المقياس. ووفقًا لحجةنا أعلاه ، هذا أمر مستحيل.
الاستنتاج
إن الربط بين الصغير والكبير هو أصعب جزء في بناء عهدنا. للانتقال من هذا الجسر إلى العهد الفعلي ، هناك بضع خطوات أخرى ، وهي سهلة نسبيا. على وجه الخصوص ، يطلب العهد أولا من المستخدم التوقيع على المعاملة باستخدام "مفتاح المولد" الخاص ، والذي يمكننا التحقق منه باستخدام رمز التشغيل OP \ _CHECKSIG. باستخدام الجالسر ، نقوم بتقسيم هذا التوقيع إلى أجزاء 4 بايت. ثم نتحقق من أن nonce كان مساويا أيضا لمفتاح المولد ، وهو أمر يسهل القيام به بمجرد تفكيك التوقيع. أخيرا ، نستخدم تقنيات من خدعة Schnorr لاستخراج بيانات المعاملة من التوقيع ، والتي يمكن بعد ذلك تقييدها بأي طريقة يريدها العهد.
هناك بعض الأشياء الأخرى التي يمكننا القيام بها: يصف الملحق C بناء توقيع الخاتم الذي يسمح بتوقيع العملات المعدنية بواسطة أحد مجموعة المفاتيح العامة ، دون الكشف عن أي منها تم استخدامه. في هذه الحالة ، نستخدم الجسر لتفكيك المفتاح العام ، بدلا من التوقيع. يمنحنا القيام بذلك تحسنا كبيرا في الكفاءة مقارنة ببناء العهد ، لأسباب فنية تتعلق ب Taproot ومفصلة في الورقة.
تطبيق نهائي أرغب في جذب الاهتمام إليه، والذي تم مناقشته بإيجاز في القسم 7.2 من الورقة، هو أننا يمكننا استخدام بناء العهد الخاص بنا لاستخراج التجزئة من توقيع Schnorr، ثم إعادة توقيع التجزئة باستخدام توقيع Lamport ببساطة.
لماذا يجب أن نفعل ذلك؟ كما جرى الجدل في الرابط أعلاه، يجعل توقيع لامبورت التوقيع بهذه الطريقة توقيعًا آمنًا ضد الكم على بيانات المعاملة؛ إذا كانت هذه البنية الوحيدة لتوقيع بعض العملات، فإنها ستكون محصنة ضد السرقة بواسطة كمبيوتر كمي.
بالطبع، نظرًا لأن بناءنا يتطلب عشرات الملايين من الدولارات للاستخدام، فلن يقوم أحد بجعل هذا البناء الطريقة الوحيدة لتوقيع عملاتهم. ولكن لا يوجد شيء يمنع شخصًا ما من إضافة هذا البناء إلى عملاتهم، بالإضافة إلى طرقهم الحالية غير الآمنة كما ذكرنا.
ثم، إذا استيقظنا غداً ووجدنا أن أجهزة الكم الرخيصة موجودة والتي تستطيع كسر توقيعات بيتكوين، قد نقترح soft-fork طارئ الذي يعطل جميع توقيعات المنحنى البيضاوي، بما في ذلك إنفاقات Taproot key وكود OP_CHECKSIG. سيجمد هذا عملياً عملات الجميع؛ ولكن إذا كان البديل هو أن تكون عملات الجميع قابلة للسرقة بحرية، ربما لن يكون هناك أي فرق. إذا سمح هذا الsoft-fork الذي يعطل التوقيع بكود OP_CHECKSIG عند استدعاء مع مفتاح المولد (مثل هذه التوقيعات لا توفر أي أمان على الإطلاق، ولا تكون مفيدة سوى كوحدة بناء لتكوينات معقدة مثل تلك لدينا)، فإن مستخدمي بنية توقيعنا Lamport يمكنهم الاستمرار في إنفاق عملاتهم بحرية، دون خوف من الاستيلاء أو السرقة.
بالطبع، سيحتاجون إلى إنفاق عشرات الملايين من الدولارات للقيام بذلك، ولكن هذا أفضل بكثير من 'المستحيل'! ونتوقع ونأمل أن نرى تكلفة هذا اسقاط بشكل كبير، حيث يعتمد الناس على بحوثنا.
هذه مشاركة ضيف من أندرو بويلسترا. الآراء المعبر عنها هي بالكامل ملك له ولا تعكس بالضرورة آراء BTC Inc أو مجلة بيتكوين.